Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

If you use a brand new product that has not been thoroughly tested by other users, you may end up performing extended beta testing for the product. If you can, wait for the second or third release.

Use a less-functional but more-mature product instead. Isolate the product so you can replace it with a more advanced model later, but let someone else do the tool company’s debugging for them. You probably have more than enough work to do building and debugging your own software without paying someone else so you can help debug theirs.

Avoid Third-Party Products

Keep your use of third-party products to a minimum. Suppose your project uses several different custom controls, a third-party database, a couple extra libraries, and special-purpose scanning hardware and software. The next time you upgrade your operating system, something is likely to break. Often it will take a lot of time just to figure out which product is at fault. Many vendors will waste a lot of your time pointing fingers at each other instead of fixing their products.

When you do know which product is to blame, you may need to install an upgrade. This will cost you extra money and may make some other product fail. That may cause you to upgrade the second product and that may cause something else to go wrong. It may take a long time and a lot of money before you again find a stable combination of upgraded products.

Another problem with third-party products is that they often do not provide support for old versions. Suppose you find a bug in a product two years after you buy it. The vendor refuses to repair the bug because that code is three revisions old, so you are forced to upgrade. The new version makes another product fail and you are stuck testing a bewildering combination of upgrades trying to find compatible versions of all of your third-party tools. Even worse, one of the products may no longer exist. Then your only choice may be an extensive rewrite of your program.

Avoid these hassles by minimizing the number of third-party products you use. Generic Visual Basic code is more likely to work with later versions of Visual Basic than any third-party product.

Also use the most generic tools possible. If a product is relatively simple, it is more likely to work when you must upgrade other products.

Note that the goal of avoiding third-party products contradicts the earlier goal of avoiding the “not invented here” syndrome. You need to carefully study the alternatives. Consider not only the risks of possible version conflict in the future, but also how hard it will be to build, debug, and maintain the code yourself.

Optimize Design, Not Code

Perform optimizations during high- and low-level design, not during coding. Changes to design can have a large impact. Changes during coding usually produce little improvement and make the code more complicated.

If you know part of the system will be slow, pick efficient algorithms for that part of the system. If a subroutine needs to manage a huge amount of data, design efficient data structures for it. These sorts of optimizations can make a meaningful difference in the system’s performance.

On the other hand, adjusting a few lines of code while leaving the underlying design unchanged is unlikely to give a vast improvement in performance. It will probably make the design less clear so it will increase the chances of bugs appearing. Tweaking one or two lines of code may speed up part of the program by a few percent. Changing the underlying algorithm can make a difference of several orders of magnitude.

After the routine is written, if you find it has an unexpected performance problem, redesign it and rewrite it from scratch. Do not try to modify the code one line at a time. You will achieve a better result if you start over and do the job properly instead of trying to patch the existing routine.

This does not mean you need to be intentionally stupid. If there is an easy way to improve performance in a subroutine, do it. However, if the change makes the code less readable, more likely to contain or hide a bug, or harder to maintain in the future, stick with a straightforward implementation until you prove it is not fast enough.

Defer Optimization

Most programs spend more than 95 percent of their time running in less than 5 percent of the code. Effort spent optimizing the remaining 95 percent of the code is wasted. It would be much more productive to spend the same amount of energy optimizing the critical 5 percent.

During the design phase, if you are fairly certain you know where the critical 5 percent of the code lies, spend some extra time designing efficient algorithms for that code. Unfortunately, it is often hard to know in advance which code will be the most critical. In that case, defer optimization until you have the program running correctly. Then some simple tests will tell you where you should spend extra time optimizing. Chapter 15, “Profiling,” discusses some ways to identify performance bottlenecks.

Deferring optimization saves the time you might have wasted improving the performance of routines that do not need it. It also avoids making those routines more complicated than necessary so they are easier to code, debug, and maintain. Finally, it is usually easier to optimize a program that runs correctly than it is to find the bugs in code that is fast but unnecessarily complex.

Indent Consistently

Consistent indentation makes code more readable. The following subroutine uses no indentation or blank space so it is relatively hard to read.

Private Sub DrawBall()
' Fix the part of the image that was covered.
BitBlt picCanvas.hDC, _
OldX - BallR, OldY - BallR, BallD, BallD, _
picHidden.hDC, OldX - BallR, OldY - BallR, SRCCOPY
OldX = CurX
OldY = CurY
' Redraw the ball.
picCanvas.Circle (CurX, CurY), BallR
' Update the display.
picCanvas.Refresh
End Sub

The following version is much easier to read because it uses indentation and blank lines.

Private Sub DrawBall()
    ' Fix the part of the image that was covered.    
    BitBlt picCanvas.hDC, _        
	OldX - BallR, OldY - BallR, BallD, BallD, _        
	picHidden.hDC, OldX - BallR, OldY - BallR, SRCCOPY    
    OldX = CurX    
    OldY = CurY
    
    ' Redraw the ball.    
    picCanvas.Circle (CurX, CurY), BallR
    ' Update the display.    
    picCanvas.Refresh
End Sub

Indent code within If statements and loops to show the program’s structure. Indent continued lines to show that they are part of the previous line. The third, fourth, and fifth lines in the previous code examples show the right and wrong way to continue long lines of code. In the first example, it takes some serious study to determine that these three lines are actually a single statement. In the second example, the line continuation is obvious.